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(57) ABSTRACT 
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regulating access to digital content includes an interface 
control processor and a specialized cryptographic unit that 
protects access to a memory. Rights keys, which allow 
access to content, are added by the cryptographic unit by 
transforming data received from the control processor and 
storing the result in the protected memory. The crypto- 
graphic unit then produces content decryption keys by using 
stored rights keys to transform other data received from the 
control processor. Because the control processor does not 
have the ability to directly access the protected memory, the 
security can remain effective even if the control processor is 
compromised. To prevent reverse engineering of the cryp- 
tographic transformations, the invention provides for an 
algorithm generator that uses random sources to produce 
algorithm definitions in machine-readable form. Because the 
generator itself does not contain any secrets, it can be 
submitted for open review. 
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FIGURE 1 [BACKGROUND ART] 
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FIGURE 2 
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FIGURE 5 
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FIGURE 6 
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FIGURE 8 
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FIGURE 11 
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METHOD AND APPARATUS FOR 
PREVENTING PIRACY OF DIGITAL 
CONTENT 

FIELD OF THE INVENTION 

The present invention relates to systems for distributing 
digital content, and more specifically to methods and appa- 
ratuses for improving the security of systems for distributing 
digital content. 

BACKGROUND OF THE INVENTION 

Introduction 

Systems that protect valuable content require effective 
security. For content distributed in physical form, such as 
film being transported to movie theaters, physical security 
measures can be sufficient. Unfortunately, traditional physi- 
cal security techniques are slow, expensive, cumbersome, 
and cannot be used with non-physical content distribution 
models. As a result, content providers rely on cryptographic 
hardware to ensure that only authorized users can access 
their data. 

To prevent misuse of decryption keys, cryptographic 
hardware used to manage content decryption keys must be 
tamper- resistant. Building effective tamper resistant hard- 
ware has proven extremely difficult, especially for systems 
that arc the subject of determined attacks, because they are 
large or protect high- value content. As a result, many 
systems (including most satellite television systems) use 
replaceable security devices, such as smartcards, so that 
security can be re-established after an attack without replac- 
ing the entire playback system. Nevertheless, smartcards 
used for prepaid telephone, pay-TV, and transit applications 
are broken regularly. For example, prepaid telephone cards 
used in Germany were attacked in 1998 with estimated 
losses of US$38 million ("Pirates Cash in on Weak Chips,'* 
Wired News, May 22, 1998). Similarly, access cards and 
systems for cable and prepaid satellite television services are 
regularly "hacked," necessitating repeated costly card 
replacements. 

Smartcards must resist a variety of attacks against cryp- 
tographic algorithms, protocols, software, and chip hard- 
ware. Unfortunately, designing a smartcard that implements 
sophisticated protocols yet contains no security flaws has 
proven to be a very difficult task, since unexpected problems 
or errors in any portion of the design can render the entire 
card insecure. Cost considerations also favor attackers, since 
smartcards typically cost between $1 and $15, yet may be 
trusted to protect services or information worth thousands of 
dollars. 

A smartcard system will only be attacked seriously if it is 
in the attacker's interest to break it. With smartcard designs 
of the background art, once attackers develop a means to 
compromise one card, the incremental cost to break a large 
number of cards is usually very small. As a result, smartcard 
security efforts typically focus on preventing the initial 
attack by making the card more difficult to break. For 
example, vendors try to increase the cost of reverse - 
engineering the device or imaging the card's ROM. Such 
techniques are helpful because they increase the cost 
required to break the system the first time, but for very large 
systems they arc ineffective because attackers will devote 
enough effort to attacks that they will eventually succeed. 

Prepayment and Post-Payment 
In many systems of the background art, digital content is 
distributed in encrypted form. Access to the keys or algo- 
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rithms required to decrypt the content is regulated by a rights 
management system that enforces the content owner's 
access policies. These access policies vary greatly in com- 
plexity. For example, the simplest schemes simply involve 
5 providing a decryption key upon payment, while the 
approaches described in U.S. Pat, No. 5,915,019 to Ginter et 
al. provide for rather sophisticated and flexible distribution 
mechanisms. 

The two most common payment methods present in such 
io schemes are prepayment and post-payment. Because these 
approaches have different security requirements, their archi- 
tectures and typical requirements will be described sepa- 
rately. 

In prepayment schemes, the user obtains prior authoriza- 

15 tion from the content provider. In typical prepayment 
systems, the user provides a payment (or a commitment to 
pay) then receives a content decryption key that allows 
access to the purchased content. 

Prepayment systems must be able to resist a variety of 
attacks. One class of attacks involves directly breaking the 
encryption (or any other protection mechanisms used to 
prevent unauthorized use of the content). Another attack 
involves capturing and redistributing the digital content after 
it has been decrypted. Other attacks involve unauthorized 
redistribution of the content decryption keys. Still other 
attacks involve capturing the content in analog form (e.g., as 
it is presented to the user). 

Some of these attacks can be prevented effectively and 

30 others do not present a serious financial threat to content 
distributors. Strong encryption algorithms (such as triple 
DES) can reliably thwart attackers who do not have the 
correct decryption keys. Attacks against the decrypted con- 
tent are not very serious if the content's value decreases 

3S rapidly with time or if the re-recording process significantly 
degrades the quality of the content. Watermarking tech- 
niques can also prevent, detect or trace some content record- 
ing attacks. Attacks that involve copying decryption keys are 
serious and have proven challenging to prevent. Because it 

40 is usually impossible or too expensive to transmit a different 
ciphertext to each potential user, attackers can purchase a 
decryption key once, then redistribute it to unauthorized 
parties. 

Systems known in the background art distribute content 

45 decryption keys in encrypted form to a tamper-resistant 
cryptographic unit connected to (or part of) the user's 
playback device. Because decryption keys with long-term 
value are never exposed in unencrypted form, many attacks 
can be prevented — if the tamper- resistant module is 

5 q unbreakable. 

Because smartcards and other tamper-resistant crypto- 
graphic hardware commonly used to implement the crypto- 
graphic unit often have limited performance and bandwidth, 
the cryptographic unit is often used to generate short-lived 

55 subkeys from the main content decryption key. These sub- 
keys are then transmitted to a less secure portion of the 
system, such as the main playback device, and used to 
decrypt the content itself. 

The security of the system thus depends on the security of 

60 the cryptographic unit. If the cryptographic unit is 
compromised, attackers can determine the decryption keys 
and algorithms and use these to access content without 
authorization (e.g. by emulating an authorized cryptographic 
unit and/or the entire playback device). 

65 In post-payment schemes, the user can decide to access 
some content without notifying the content provider or 
obtaining permission in advance. Instead, the content pro- 
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vider later audits the user's usage and determines the appro- Commercially-deployed approaches usually use tamper- 

priate fees to charge. In some systems of the background art, resistant hardware modules to enforce the content provider's 

post-payment is referred to as pay-per-view. access policies. FIG. 1 shows a smartcard of the background 

In addition to being susceptible to the attacks described art for regulating access to encrypted content. The exem- 

above against prepayment systems, post-payment schemes 5 plary system includes three types of memory 110: ROM 115 

are vulnerable to a variety of additional attacks. For EEPROM 125, and RAM 120. E*ch type of memory has 

example, the user's purchase audit records must be stored advantages and disadvantages. ROM is fast and inexpensive, 

until the content provider retrieves them. Modification or but cannot be modified and can often be read using advanced 

destruction of these records can make it impossible for the imaging techniques. RAM is fast and can be updated 

content provider to determine the correct amount to charge. 10 quickly, but loses its contents when power is lost. EEPROM 

As a result, secure storage is required in the cryptographic retains its contents even when power is disconnected, but is 

unit for the audit data. relatively expensive to manufacture and is quite slow to 

Although cryptographic techniques can secure the audit modify, 
data from tampering (provided that the cryptographic unit R0M and/or EEPR0 M generally include software, 
has not been compromised), users generally do have the is which * executed, by microprocessor 140. The software 
ability to prevent the audit process altogether. For example, mcludes instructions that implement and/or manage proto- 
in many consumer systems, two-way communication cols and cryptographic keys involved in decrypting content, 
requires a telephone call which users can prevent by simply Because cost} ^ and I/Q bandwid th limits make it 
disconnecting the telephone line. Users can often even difficult t0 decrypt a large amount of data in the t r _ 
destroy the cryptographic unit to conceal their purchases. As 20 resis tant module, the tamper-resistant module can supply 
a result measures are generally required to make users allow contenl deC ryption keys for individual blocks or streams of 
audits. For example, it is possible to penalize users by conte nt to the playback system, which performs the bulk 
terminating service or preventing access to additional post- data decry pti 0 n. A cryptographic processor 150 can option- 
payment (pay-per-use) content if successful audits are not ally assist wit h the cryptographic computations by reducing 
performed m a timely manner. Back-end systems can also 25 the amount of time 0 r program code required for the 
charge users with penalties or other fees for audit noncom- computation or by implementing obfuscated algorithms that 
pliance. are difficult to reverse engineer. 

Post-payment systems involve more risk because pur- tw t . . , , 

. * J ... 7 ... . , . ... v To support both prepayment and post-pa ymen , at least 

chases occur without live interaction with the content pro- f. K „Jj . nnarnt * * ' i,r< • . * ia* 

., A . . ,. . t , „„ four basic operations are supported over I/O interface 145: 

vider. As a result, each cryptographic unit must be prepro- 30 ... „„, „„ A E * 1 j- 

• ... A. ; 1 c • • ,. adding new prepaid rights keys or privileges, recording 

grammed with the cryptographic keys for viewing a „™ul™ se » a a • . . j 

* t t t . • k» -ui u a purchases (for post-payment), deriving content decryption 

content the user might possibly purchase. As a result, f,~.,„ *u / . ,\ J 

& l • j 1 lvoull » keys (for either prepayment or post-payment), and post- 
compromise of a single cryptographic module can poten- pa y m e nt auditing 

tially compromise all post-payment content in a system. JL , . , ™« * . „ , , , . 

x , , „ t u- . 1 t „ The device of FIG. 1 can potentially be attacked m a 

Many systems combine prepayment and post-payment 35 . f . ^ • 3 

, n * ■ 1 1 j r v j variety of ways. Attackers typically begin by extracting the 

approaches. Prepayment is generally used to regulate access „ / A e a ■ • / • j ■ 

to content sold on a subscription bak For example, access *? f *™ ° De 'T" 8 I ?° 

to electronic news services, music channels, subscription ° f . tech »W s « cb ^ phyacaUy rmaging a chip or mod., 

television channels, etc. are commonly sold on a prepayment * " g v * ' ^ Chl f P US1 ° g l0n h ' h ° 8 " P , hy C S 

basis. Premium content is often provided on a post-payment « echQK > Ue * P erf °"™e the ROM and/or EEPROM 

(pay-per-use) basis, where users can use content at any time I*™*™ a " rela,1Vel .y K " ,he "J*" 1 "" onl y has , 0 

L iLr k- « i i • r 11 i .u be performed once, since all units in the system normally 

but their cryptographic modules periodically provide the . , „ . ft 0 4 / . . J 

^r,i»«i «™ -a *u r « r.u * . .u . u nave the same or similar software. Some techniques, such as 

content provider with a list of the premium content that has , • 

, ,„~a n«„. . « . t.u- . j • . • (iri . „ tamper-resistant chip coatings, memory encryption, etc. can 

been used. Post-payment or this type is used m he Divx , . . . » „ i i_ * i_ L ■ 

, ii . ui j . ,c complicate memory extraction attacks, but such techniques 

video playback system as well as most cable and satellite 45 ** j , m 

t 0 u,;oL «L , ■ ^ u n- i are expensive to implement and only increase the cost for 

telev^.on pay-per-v.ew' schemes. Prepayment protocols performing |he Mf £ m extraction . 



can be used for extremely high value pay-per-view content 



if penalties are insufficient to ensure successful auditing or 0nce the software 1S known > attackers can reverse engi- 

if the risks are great enough to offset the cost and effort to , necr the code ' y ieldin 8 a11 cryptographic algorithms and 

initiate two-way communication with the content provider 50 kevs contained in the extracted regions. Again, some 

before access is authorized techniques, such as the use of obfuscated or nonstandard 

software, can complicate this process somewhat. 

The Cryptographic Rights Unit (CRU) If cryptographic processor 150 is not present, the attacker 

A variety of designs and architectures have been proposed can then produce an emulator of the target device. Once an 

and used for cryptographic units that manage and protect the 55 emulator has been developed, it is often difficult for the 

secret keys and algorithms used in content distribution provider of the system to re-establish security without 

systems. If legitimate users can be trusted to protect their replacing all CRUs. Even if legitimate devices are config- 

keys, software-only approaches can be acceptable and have ured to allow updates to the portions of their software or 

the advantage of avoiding the cost and expense of building keys in EEPROM, the emulator will simply accept the same 

and distributing specialized hardware. In many cases, 60 updates and continue operating unless the content provider 

however, tamper-resistant modules are required, manages to identify the compromised keys and stop provid- 

No architecture can provide perfect security. For example, ing service to the corresponding accounts, 

an exact replica of an authorized satellite television receiver If the emulator is imperfect and legitimate devices are 

(including the receiver's cryptographic rights unit) will be configured to allow software updates, it may be possible to 

able to view the same signals as the original. As a result, the 65 modify legitimate devices in a way that the emulator will not 

security depends on preventing attackers from building process correctly. Unfortunately, all the attacker has to do is 

working copies or emulators of authorized playback devices. correct the emulator. For example, pirates have produced 
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CRU emulators that operate a persona! computer and 
updated their emulator software to fix any errors in the 
emulator's operation. 

Code update capabilities are a double-edged sword — 
although they can thwart some attacks, attackers may be able 
to subvert them to inject malicious code into legitimate 
devices. Although code updates can be protected with digital 
signatures and/or MACs (Message Authentication Codes), 
attacks against the hardware, software, and/or cryptography 
pose a significant risk. It may also be possible for attackers 
to insert code in other ways, for example by exploiting 
pointer errors to redirect memory updates to code regions. 

For example, if the attacker is able to trick microprocessor 
140 into executing malicious (i.e., attacker-written) code, 
then the attacker can use the first code to load more 
malicious code into EEPROM 125 or RAM 120. This 
malicious code can then further modify the device, for 
example by adding unauthorized functions that bypass non- 
cryptographic protections, delete post-payment audit 
records, add/modify/output cryptographic keys such as 
rights keys, etc. Although some techniques (such as hashing 
EEPROM contents as part of key derivation processes) have 
been attempted to detect some such attacks, these techniques 
tend not to be very effective and have been evaded by clever 
attackers. Although it would be possible to make micropro- 
cessor 140 execute only code from ROM 115, the system 
designers would then be unable to patch problems or trans- 
mit code updates to address bugs. 

It is extremely difficult or impossible to reliably prevent 
all major attacks using architectures of the background art. 
Once attackers reverse engineer the software executed by 
microprocessor 140, they can identify and exploit software 
flaws or other implementation weaknesses. If these weak- 
nesses in turn allow unauthorized modification of the 
device's software, the content provider's own cryptographic 
rights units (CRUs) and/or playback hardware can even be 
used to attack the system. The book European Scrambling 
Systems 5 by John McCormac (Baylin Publications, 1996) 
contains more information about how some existing systems 
have been designed and attacked and why architectures of 
the background art have proven ineffective. 

Using architectures of the background art, any weakness 
in the cryptographic unit thus tends to cause a serious 
compromise of the entire device. Building a device that 
resists all known invasive and non-invasive hardware 
attacks, software attacks, protocol attacks, cryptographic 
attacks, fault induction attacks, etc. is extremely 
difficult — and new attacks may be discovered after a device 
is deployed. As a result, many content providers suffer from 
high piracy rates and the expense of replacing cryptographic 
units when they are broken. 

SUMMARY OF THE INVENTION 

The present invention can improve the security of systems 
used to distribute and protect digital content. One embodi- 
ment of the invention, in a tamper-resistant device for 
regulating access to encoded digital content, includes an 
external interface, a microprocessor for controlling the 
external interface, a memory, a cryptographic unit connected 
between the microprocessor and memory configured to 
protect the memory from the microprocessor by crypto- 
graphically transforming data communicated between the 
microprocessor and the memory, and a device key accessible 
by the cryptographic unit and inaccessible by the micropro- 
cessor. The device is configured such that the cryptographic 
unit uses the contents of the memory to transform at least 
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one data value received from the microprocessor, where the 
result of the transformation is required to decode the digital 
content. 

Although it is impossible to design a content distribution 

5 system that is immune to all possible piracy attacks, the 
main objective of the present invention is to minimize the 
probability that attackers will profit from attacks. A system 
does not need to be immune to all attacks; attackers are 
generally rational and driven by a profit motive, so illogical 

1Q attacks will not proliferate widely. For example, if the 
attacker's cost and risk exceed the cost of purchasing the 
content legitimately, piracy is not a serious threat. 

Attackers have both advantages and disadvantages as 
compared to legitimate service providers. Because their acts 

15 are often illegal, they incur higher risks. Their distribution 
costs and customer acquisition costs tend to be higher, since 
they generally cannot use traditional (legitimate) channels. 
The quality and reliability of pirate services also tends to be 
inferior. On the other hand, attackers have several major 
advantages. Most important, they obtain their content for 

20 free (i.e., by pirating it). In many cases they also co-opt part 
or all of a content provider's distribution channel (e.g., sales 
of encrypted optical discs, satellite broadcasts, Internet 
services, etc.), playback mechanisms (cable TV set-top 
boxes, DVD players, etc.), and other infrastructure. Finally, 

25 pirates* customers may be able to avoid cumbersome pro- 
cedures imposed by the legitimate content provider for 
security, billing, etc. 

Although attacker business models vary, the present 
invention is based on the premise that content providers can 

30 effectively eliminate piracy by making it unprofitable. It is 
thus an objective of the present invention to increase the 
costs and risks incurred by attackers who steal content. 

The present invention is also based on the premise that 
content providers will only invest in anti-piracy measures 

35 that make business sense. When estimating the cost of 
content piracy to content providers, several factors that must 
be considered. Direct revenue losses occur when potential 
subscribers instead buy pirated content. In cases where 
content providers subsidize the costs of media, distribution, 
playback hardware, technical support, etc., illegitimate users 

40 can also increase expenses. If piracy is widespread, content 
providers may be unable to obtain premium content or will 
have to pay more to content owners to compensate them for 
lost royalties. Costs for enforcement and prosecution can 
also be significant. Paying users may even feel discouraged 

45 if they see others getting for free what they are paying for, 
reducing the perceived value of a service. It is thus a primary 
objective of the present invention to achieve improved 
security without unduly increasing costs or hassles for 
content providers or legitimate users. 

50 Traditional content protection schemes generally seek to 
maximize the cost of any unauthorized access, but do little 
to increase the cost of decoding messages once the decryp- 
tion scheme has been broken. In addition to preventing 
attacks, the present invention also seeks to minimize the 

55 proliferation of unauthorized decoding devices if an attack 
does occur, since the damage due to piracy increases with 
the number of unauthorized users. It is thus an objective of 
the present invention to maximize the cost of producing 
multiple unauthorized pirate devices even after one device 

60 has been compromised. This objective is attained in part by 
forcing attackers to repeat complex and expensive 
physically-invasive attacks for each pirate device that is 
produced. 

65 BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a smartcard of the background art for 
regulating access to encrypted content. 
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FIG. 2 shows an exemplary system using the Crypto- Digital content; A digital representation of human- 
graphic Rights Unit (CRU) of the present invention. interpretable material, such as pictures, audio tracks, video 

FIG. 3 outlines an exemplary embodiment of a process for segments, text (such as books, magazines, news feeds, stock 

adding rights using prepayment. quotes, etc.), etc. Digital content is often encrypted and/or 

FIG. 4 outlines an exemplary embodiment of the rights 5 compressed and may include error correcting codes and 

addition process using post-payment. otner auxiuarv data - 

FIG. 5 shows an exemplary method of the present inven- Interface Control Processor (ICP): A microprocessor 

lion for deriving CDKs using rights keys stored in the responsible for processing communications between the 

CryptoFirewall's protected memory. cryptographic rights unit and a playback device. The ICP is 

FIG. 6 shows exemplary processes for auditing and clear- 10 ^ ^^ {{ reS P 0Dsible for c ™nWating with the 

ing audit data. ™P 

r, r - j' ov ^.„ r miil .- , , • ISO 7816 Smartcard: Adevice complying with at least the 

HG. 7 diagrams an exemplary multi-targeting technique . . _.. , / . . • 

c t . , . j u u -f u ? t physical dimensions and contact configurations specified in 

of the present invention and shows how it can be used to ; ' _._•-«,.,*-• « & , v 

renew riehts keys standard 7816-1 and 7816-2. Smartcards are commonly 

t-t^ J .1- . 15 us ^d t0 implement CRUs, as they provide a reasonable 

HG. 8 illustrates one embodiment of a pseudoasymmetnc d of r resistance a , relatively low cost, 

function generator (PAFG) of the present invention. r_ _ . . w „ rr , . « A 

__ . , . , ^ Key Derivation Message (KDM): A message generated by 

FIG. 9 diagrams the operation of an exemplary Crypto- a con(em ider , 0 al|ow a CRIJ , 0 derive a decryption key 

Firewall that implements prepaid rights and can be easily corresponding t0 sorae digital content . kd Ms are usually 

extended to support post-paid rights. 20 lransmiUed ^ the correspond i ng conlent . 

HG. 10 shows an exemplary CryptoFirewall embodiment Playblck Device: A device that receives digital content 

using a small volatile protected memory and using batch vja aQ u[Urusted mechanism (such ^ radio tical disCt 

keys to minimize the bandwidth required for REMs. digiu , audio (ape> cabkj MtelUte broadcast> Internet 

FIG. 11 diagrams the content decryption key computation connection, etc.) and, using a CRU, decodes the content. The 

process of FIG. 10. bulk data decryption operation can be performed by the 

DETAILED DESCRIPTION OF THE CRU itself or by the playback device using a key generated 

INVENTION b V the CRU - 

„,„.,... , , , Pseudoasymmetnc Function: A function (transformation) 

The following description is presented to enable any Jesi ^ sud) mat cannQt easj , fom) , he 

person skilled in the art to make and use the invention, and mverse transformation even with dil6Ct access t0 the for . 

is provided m the context of a particular application and its war(J trimsformatioi] . Por example) an attacker ^ access t0 

requirements. Various modifications to the disclosed a pseudoasyinmetric encryption function does not necessar- 

embodiments wiU be reach y apparent to those skiUed w the a bave , be ibM , 0 d , meaningful meS sages. Unlike 

art, and the general principles defined herein may be applied traditional aS y mmetric cryptographic functions, however, 

to other embodiments and applications without departing ^ noninvertability of a pseu doasymmetric function relies 

from the spirit and scope of the present invention. 0Q the difficuUy of compUlely reverse engineering the 

Definitions "public" function instead of the difficulty of performing a 

. ^ . . _ mathematically hard operation such as factoring. A block 

Asymmetric Function: An easy-to-compute function for cipher implementation with a physically-protected key and/ 

wh.ch a complementary operation (such as its inverse) is Qr al rithm that onl ^ encryption * an example of 

computationally hard w.thout a pr.vate key, but easy to a ps6udoasymmetric since unres , r i c ted access to 

compute with the private key. The RSA cryptosystem is (he en tion lion a]one does nol allow decryption of 

thought to be asymmetnc, since inverting the public key messaees 

operation (i.e., performing the private key operation) is only * , "_ , , w /Ptl -»,x A 

easy with if the private key is known. « Enablement Message (REM): A message gener- 

' n . „ . , , ated by a content provider that gives a CRU the ability to 

Content Decryption Key CDK): A key required to access new conlem The REM iLsdf is usually transmitted 

decrypt some encrypted digital content. via (he same untrusted mecnanism as the content itself, 

Content Provider: An entity that manages the crypto- although in some cases REMs may be exchanged through 

graphic portions of a content distribution system. The con- 50 other channels (such as separate telephone or Internet 

tent provider is also generally responsible for distributing or connections). 

broadcasting the content, billing, customer service, etc. The Ri ^, s Ke A va[ue (such as a cryptograpbic key) that 

content provider tasks can be div.ded among many compa- aUows a CRU , Q genera(e Qr decode (be decryption keys for 

nies ' some content. Rights keys are generally required to decrypt 

CryptoFirewall: A specialized circuit placed between the 55 kd Ms and obtain content decryption keys, 
interface control processor (ICP) and a protected memory Tamper-Resistant Device: A hardware device whose 
which is designed to control access to (and use of) the ion ^ relatively difficu „ t0 monitor and/or modify . 
protected memory even .f the ICP is compromised. In Ex a ks of tarapcr . r e S i slan , devices include without limi- 
addition, the CryptoFirewall uses the protected memory to la(ion PCMCIA cards flllcd with cpoxyj circuils 
derive content decryption keys. 60 wi(h Ump e r . r e sistan , coalings> circuits wrapped in tamper- 
Cryptographic Rights Unit (CRU): A tamper-resistant de ,ecting wire, integrated circuits (which are tamper rcsis- 
hardware device designed to perform cryptographic opera- tam due , 0 their smaU fealure si2e)> and dicuil> in enclo . 
lions that allow authorized users to gain access to digital sures , hat delcct opening 
content. 

Device key: A cryptographic key or other security-related i>5 System Architecture 

parameter that is preferably specific to a particular device, FIG. 2 shows an exemplary system using the Cryplo- 

but may also be shared by a small number of similar devices. graphic Rights Unit (CRU) of the present invention. Content 
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Provider 200 obtains content and prepares it for distribution, 
for example by compressing and encrypting content data, 
multiplexing multiple content streams, and adding control 
messages such as KDMs and REMs. (A more detailed 
explanation of the content preparation process is provided in 
the section below entitled "Preparing Content.") 

The encrypted content data is then distributed (process 
205) by the Content Provider in a manner such that it can be 
received by authorized (e.g., paying) users as well as poten- 
tial attackers. A variety of distribution methods may be 
employed, including without limitation distribution of 
physical media (such as optical discs), radio or satellite 
transmission, wired networks (such as telephone, ADSL, 
cable television, etc.), and distribution over computer net- 
works (such as publication on a web site, multicast, etc.) 

Playback device 210 receives the distributed data for 
some content to be decoded. In the exemplary embodiment 
shown in FIG. 2, Key Distribution Messages (KDMs) and 
Rights Enablement Messages (REMs) are distributed with 
content 205. Playback device 210 thus separates the desired 
content 215 and control messages 220 in the received data. 

In the exemplary embodiment, control messages 220 
include Key Derivation Messages (KDMs) and Rights 
Enablement Messages (REMs). These messages are trans- 
ferred by playback device 210 to Cryptographic Rights Unit 
(CRU) 225. Playback device 210 can optionally perform 
processing or filtering before sending messages to CRU 225. 

CRU 225 includes an interface control processor (ICP) 
235, which is responsible for communication with playback 
device 210 via I/O interface 230. In addition, CRU 225 
includes several types of memory connected to interface 
control processor 235 via bus 240. In particular, fixed data 
and code are stored in ROM 245, temporary data (and 
possibly code) are stored in RAM 250, and additional code 
and/or data are stored in EEPROM 255 which can be 
modified by processor 235. Also attached to bus 240 is 
CryptoFircwall 260, a specialized cryptographic processing 
unit whose operation is explained in detail below. Crypto- 
Firewall 260 regulates and cryptographically modifies data 
written to or read from protected memory 265. 

To decode some content, playback device 210 transmits to 
interface 230 a KDM corresponding to some content 215 to 
be decoded. Interface control processor 235 receives the 
KDM and, as described below, uses CryptoFirewall 260 to 
derive one or more content decryption keys 267, which are 
transferred to bulk decoder 270 via playback device 210. 
With the correct keys 267, bulk decoder 270 can correctly 
decrypt content 215. The decrypted content 275 is then sent 
to an output device 280, which presents the content to user 
290 by converting it into a hum an -readable form (process 
285). For example, if the system is configured to play audio 
content, decrypted content 275 could be an analog or digital 
representation of a sound, and output device 280 could be an 
amplifier and speakers. Similarly, if the system is configured 
to play movies on a television set, bulk decoder 270 could 
perform decryption and MPEG decompression, outputting 
decrypted content 275 as an NTSC-compatible video signal 
so that ouiput device 280 can be an ordinary television set. 

A communication channel from CRU 225 to content 
provider 200 is also provided for auditing post-payment 
purchases This channel can also be used for transmitting 
REMs, other usage data, code updates, etc. Communication 
from the CRU to the content provider can be direct 296 or 
(more commonly) indirect 295, e.g. passing through play- 
back device 210 which can (for example) establish a con- 
nection with content provider 200 as needed. Any commu- 
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nication method (including without limitation modem, 
radio, satellite, cable, etc.) can be employed. 

CryptoFirewall Operation 

The CryptoFirewall cryptographically regulates access to 
a piotected memory. Unlike conventional memory encryp- 
tion devices (such as the encrypted memory device of U.S. 
Pat. No. 5,442,704 to Holtey), the CryptoFirewall does not 
act transparently or allow arbitrary read or write operations 
to be performed by the microprocessor. In particular, the 
CryptoFirewall does not need to provide the microprocessor 
with the ability to store data values in the protected memory 
and read the same values out later. Conventional secure 
memory schemes are typically used to allow a trusted 
computational device to access memory that is less secure. 
In contrast, the CryptoFirewall is designed with the opposite 
assumption, that the interface control processor is untrusted 
but attackers do not have direct read/write access to the 
memory behind the CryptoFirewall, In other words, the 
CryptoFirewall can allow the cryptographic rights unit to 
remain secure even if the CRU's main microprocessor is 
compromised, provided that attackers do not completely 
breach the firewall and gain unrestricted access to the 
protected memory. 

The CryptoFirewall implements a set of basic operations 
involved in adding and using content access rights. In the 
exemplary embodiment described with respect to FIGS. 3, 4, 
5, 6, and 7, these operations include adding new rights by 
prepayment, adding new rights for post-payment, accessing 
content, auditing/clearing post-paid purchase audit records, 
and renewing rights. The interface control processor is 
responsible for supplying data to the CryptoFirewall for 
each of these commands and assisting with non-security 
critical tasks. 

The exemplary CryptoFirewall uses several keys, which 
are stored in protected memory 265 and loaded during 
personalization (described below). In one embodiment, the 
protected memory is an EEPROM containing a device key 
(CHIP_KEY), at least one group key shared by (for 
example) 32 cards (BATCH_KEY), a post-payment autho- 
rization key (POSTAUTH„KEY), and several rights keys. 
Portions of the protected memory containing device keys 
and group keys can be written during personalization, then 
locked (write protected) to prevent future modification. 
Alternatively, these values can be stored in ROM, within or 
accessible by the CryptoFirewall. 

Adding new rights by prepayment: FIG. 3 outlines an 
exemplary embodiment of a process for adding rights using 
prepayment. When a user purchases (or otherwise obtains) 
permission to use some content, the playback device 
receives an appropriate rights enablement message (REM) at 
step 300. The REM is optionally processed and/or validated 
by the interface control processor, which locates an 
encrypted rights key in the REM. The interface control 
processor also selects a destination address in the protected 
memory. At step 310, the encrypted rights key and address 
are transferred to the CryptoFirewall, which performs the 
subsequent processing steps (labeled 320). At step 330, the 
CryptoFirewall validates that the address specified is valid 
for storing prepaid rights. At step 340, the CryptoFirewall 
reads CHIP ..KEY (a chip-specific key or device key) from 
the protected memory. At step 360, the encrypted rights key 
is transformed using pseudoasymmetric function F lf keyed 
using CH1P_KEY. At step 370, the CryptoFirewall stores 
the result of transformation F J( (i.e., the rights key) in the 
protected memory at the validated address. Note that the 
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process of FIG. 3 can also be used to delete or replace rights charge users for post-payment purchases. To perform an 

keys (e.g., by over-writing them), although key deletion is audit, the content provider must be able to receive data from 

not essential for broadcast systems (such as cable or satellite the cryptographic rights unit, for example through a modem 

television) since content providers can simply stop distrib- or computer network connection with the playback device, 

uting content protected using expired keys. 5 audit process can be combed by the interface control 

Adding new rights by post-payment: Rights added by processor, which in turn communicates with the CryptoFire- 

post-payment are different from prepaid rights because no wall . FIG. 6 shows exemplary processes for auditing and 

exphcit communication or prior authorization is available ckari audit dala Al st m the t ider trans . 

n! ° t h m nv ° UthneS 3n eXCmpla 7 mits an audit initialion ^« mes ^ ; the interface 

™1T 1 h Pr0Ce ? ^ P 10 contro1 P rocessor - (The process used to initiate audits is 

payment. When a user wishes to gain access to content on a • i ♦ - c ^ L " r t , 

post-paid basis, the interface control processor obtains at ^plementation-specific. For examp e, the CryptoFirewall 

step 400 a rights enablement message corresponding to the or CP can ^rnaUvcly notify the playback device that an 

content access right to be added. The REM includes an audlt 1S needed so thal lhe P la y back device can establish a 

identifier of the content. (The content identifier can be a connection with the content provider. In another embodi- 

simple identifier, a randomly produced or cryptographically 15 meDt the 001116111 provider can broadcast a message to the 

generated value, a counter, a combination of parameters, etc. CRU requesting that it perform an audit. In another 

and may be generated by the content provider, ICP, playback embodiment, the content provider can directly establish a 

device, CryptoFirewall, etc.) At step 410, the content iden- connection with the CRU or playback device.) The exem- 

tifier and a destination address are passed to the plary audit initiation message includes an unpredictable 

CryptoFirewall, which performs the subsequent processing 20 and/or unique challenge value generated by the content 

steps (labeled 420). At step 430, the CryptoFirewall verifies provider. At step 610, the CryptoFirewall receives an 

that the address is valid for storing post-paid rights. At step address value and the challenge value corresponding to a 

440, the CryptoFirewall verifies that storing audit data at the first address to audit. At step 620, the CryptoFirewall verifies 

specified address will not replace an existing post-payment that the address is valid for auditing. At step 630, the 

purchase record in the protected memory. At step 460, the 25 CryptoFirewall retrieves the contents of the protected 

CryptoFirewall uses a pseudoasymmetric function F 2 to memory corresponding to the specified address and a device 

transform the content identifier. (The function F 2 can, for key (c>frf C HIP_KEY). At step 640, the CryptoFirewall 

example, be keyed with a post-payment authorization key combines the memory contents and the address (for example 

POSTAUTTH KEY or a global key or, if separate post- by concatenating them or replacing part of the memory 

payment KDMs are distributed for batches of CRUs, a batch 30 contents with the address) and transforms the result using 

key ) At step 470, the CryptoFirewall stores the result (the pseudoasymmetric function F 4 keyed with the CHIP„KEY 

rights key) in the protected memory. X0Red with mc cha i Ienge valuc . ^ ICP then receives the 

Accessing content: Before a user can access some content, F 4 result and sends it to the content provider via the playback 
the playback device must obtain the correct content decryp- device. At step 650, the content provider uses F 4 _1 (the 
tion key (CDK) so that the content can be decrypted. FIG. 35 inverse of F 4 ) keyed with the CRU's CHIP_KEY XORed 
5 shows an exemplary method of the present invention for with the challenge value to determine the actual contents of 
deriving CDKs using rights keys stored in the CryptoFire- the memory at the specified address. Because F 4 is 
wall's protected memory. At step 500, the interface control pseudoasymmetric and keyed using the CHIP_K£Y, the 
processor (ICP) receives a key derivation message (KDM) content provider (and only the content provider) should be 
from the playback device. Al step 510, the ICP uses the 40 able to perform F 4 '\ Unless an attack or computational 
KDM to obtain a CDK generator value. (The CDK generator error has occurred, the decryption result should correspond 
is typically an encrypted form of the CDK and is part of the to either an unused (empty) post-paid rights slot or a rights 
KDM.) The ICP then sends the CDK generator and an key for content sold on a post-payment basis. At step 660, 
address in the protected memory corresponding to the appro- the content provider decides whether to clear the slot that 
priate rights key to the CryptoFirewall, which performs 45 was audited. (Post-payment purchase records that are no 
steps 520 through 560. (To assist with selecting the correct longer needed by the CRU should be cleared to make room 
address, the ICP can use its nonvolatile memory to keep for new purchases.) If no clearing is to be performed, 
track of the rights keys and their locations. The KDM also processing continues at step 690. Otherwise, at step 670, the 
can identify which rights key is appropriate for processing content provider applies F^ 1 again (keyed using CHIP_ 
each CDK generator.) At step 520, the CryptoFirewall 50 KEY) to the result of the first F 4 ~ a transformation. The result 
verifies that the address is valid, then, at step 530, retrieves is transferred to the CryptoFirewall via the playback device 
the corresponding value (the rights key) from the protected and the ICP. At step 675, the playback device applies F 4 
memory. At step 550, the CryptoFirewall uses pseudoasym- (keyed using CHIP KEY) to the value received. At step 680, 
metric function F 3 , keyed with the rights key that was read the playback device compares the result with the value read 
from the protected memory at step 530, to transform the 55 from the protected memory at step 630. If the values match, 
CDK generator. (In an alternate embodiment, F 3 can be the CryptoFirewall performs step 685 and clears the pro- 
keyed with the CDK generator and used to transform the tected memory slot. At step 690, the audit process repeats 
rights key itself. Also, F 3 does not necessarily need to be a back to step 610 if more addresses in the protected memory 
pseudoasymmetric or invertable function. For example, F3 ncc d to be audited. Otherwise, the audit process concludes, 
can be a hash ) Al step 560, the CryptoFirewall returns the 6 o After a successful audit, the content provider performs 
transformation result to the ICP. At step 570, the ICP post-audit actions such as charging the customer for pur- 
optionally performs any final processing required to produce chases and refreshing pre-paid keys in the CRU. If the audit 
the final CDK from the F 3 result. At step 580, the ICP fails or indicates inappropriate (or unknown) values in the 
transmits the CDK to the playback device, which, at step protected memory, actions might include terminating service 
590, uses the CDK to decrypt the content. 65 l0 thc pi ayb ack device (or CRU), requiring the user to return 

Auditing and Clearing Post-Payment Rights: A secure the CRU for replacement, billing the user for 

audit process is required to allow the content provider to noncompliance, and/or sending messages to cause the CRU 
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to disable itself The embodiment shown in FIG. 6 is exem- Personalization 

plary; alternative embodiments can, for example, perform ~ . ... . . . ,. , p „ !n 

auditing before audit record clearing begins, use risk man- ? U ™^ lh °. ^^-^ 

agement techniques in the CryptoFirewall to require audits and BATCH_KEY are added. If manufacturing processes 

and determine when they should occur, corrupt audit records 5 allow ' lhese kevs can be stored m the CryptoFirewall during 

if audit clearing authorizations are invalid, accumulate a manufacture, for example by blowing on-chip fuses. They 

hash of the audit data in the protected memory so that can also be slored in the protected memory, but care should 

insecure memory can be used to store audit records, modify be taken, however, to prevent attackers from being able to 

protected memory fields during the auditing process as well store key values from one CRU in another. Methods usable 

as during the record clearing process, etc. to prevent such attacks include preventing write access to 

Multiple Targeting: In some environments, it may not be the key regions after personalization (e.g., by blowing a 

feasible to broadcast different REMs to all users. For write -protect fuse), cryptographically regulating access to 

example, if REMs are distributed with content stored on these regions, and disabling either bit clearing or bit setting 

optical discs, broadcast by radio, or sent via satellite, the operations to prevent attackers from transforming one key 

data required for REMs is typically distributed to all users. into another. (Valid keys can be chosen with equal numbers 

As a result, the bandwidth and cost for distributing REMs 15 0 f set and clear bits to ensure that key changes will require 

increase as the system grows larger and can eventually both setting and clearing bits.) It is even possible to allow 

become prohibitive. It is possible to reduce the amount of modification of the keys, provided that changes performed 

RE y„*J?w b JJ aUowm S rauUl P le authorized CRUs to use using non -invasive attacks have a high probability of cor- 

each REM. FIG. 7 diagrams one exemplary multi-targeting t{ the k without producing useful resultSt 

technique ot the present invention and shows how it can be 20 

used to renew rights keys. At step 700, the playback device Pseudoasymmetric Function Generation 
receives a REM, which includes a rights key fixup value 

encrypted with a key shared by a batch of CRUs as well as Pseudoasymmetric functions are included in preferred 

several smaller (e.g., 3-bit) chip-specific fixup values. For architectures as they can help limit the consequences if a 

example, if a BAXCH_KEY is shared by 256 CRUs, a 25 sin S Ie device IS compromised. Cryptographic protocols 

separate 3-bit chip fixup value is included for each of these alone ( wltnoul hardware tamper resistance) cannot prevent 

CRUs authorized to use the REM. At step 710, the Crypto- man y altacks a * ainsl broadcast <*> nlenl distribution systems, 

Firewall receives the rights key fixup value, the address to since aD unauthorized replica of an authorized playback 

update, and the chip-specific fixup value designated for this s y stem Wl11 be able 10 decode si S nals - M a result ' the 

CRU. At step 720, the CryptoFirewall validates the address 30 hardware implementation should be difficult to reverse engi- 

received from the interface control processor to ensure that neer or c * one - 

it corresponds to an updateable key in the protected memory. In one embodiment, a pseudoasymmetric algorithm is 

At step 730, the CryptoFirewall reads the CHIP_KEY from produced using a software-implemented generator. The gen- 

the protected memory. At step 740, the CryptoFirewall uses erator constructs a randomized algorithm using data from a 

pseudoasymmetric function F s keyed with CHIP_KEY to 35 random number source, such as a true random number 

transform the rights key fixup value. At step 750, the F 5 generator, a pseudorandom number generator (such as a 

result is truncated or compressed to a 3-bit quantity and the stream cipher), a pre-computed randomized input file, etc. 

truncated value is combined with the 3-bit chip-specific generator uses the random data to automatically design 

fixup value received at step 710. (The combining can be a hardware circuit that performs a cryptographic transfor- 

done, for example, by XORing the two 3-bit values together, 40 rnation. The purpose of the random source is to ensure that 

adding them modulo 8, etc.) Note that the result of step 750 tne circuit construction and the function it performs are 

will match a value chosen by the content provider if the unknown to attackers. 

chip-specific fixup value is correct, but otherwise produce a FIG. 8 illustrates one embodiment of a pseudoasymmetric 

different value. An attacker who attempts to guess the function generator (PAFG) of the present invention. The 

chip-specific fixup value will cause the result of step 750 to 45 input message is stored in a 128-bit shift register 800. The 

be incorrect 7/8 (87.5 percent) of the time. At step 760, the contents 810 of shift register bits 1 though 127 are labeled 

3-bit result of step 750 is combined with the rights key fixup Uj, through U J27 . In addition, the 128-bits of a permutation 

value received at step 710, for example by XORing the selector (key) K are also available as K$ through K 127 

result of step 750 onto the first 3 bits of the rights key fixup (labeled 802) and a clock cycle counter C is available as C 0 

value. At step 770, the CryptoFirewall reads from the 50 through C 15 (labeled 804). The computation circuit includes 

protected memory the data at the address received at step a series of sixty-four NAND gates 820 having inputs V 0 

710 and XORs with the BATCH_KEY. (If the BAXCH_ through V 127 (labeled 815). For each NAND gate, the PAFG 

KEY is stored in the protected memory, it is also read at this uses its random source to randomly select one input bit from 

step.) At step 780, the CryptoFirewall transforms the result U lt through U 127 and to randomly select the other input bit 

of step 760 using pseudoasymmetric function F 5 , keyed with 55 from among C 0 . . . C 15 , Kg . . . K J27 , and U 3 . . . U 127 . (To 

the result of step 770. Finally, at step 790, the result is ensure that the transformation in this exemplary embodi- 

written to the protected memory at the specified address. ment is a permutation, the leftmost shift register bit, labeled 

Because the attempts to perform an unauthorized key update 805, is not used here.) 

will corrupt the key most of the time (i.e., with probability The outputs of NAND gates 820 are labeled W 0 through 

2~* for a k-bit chip-specific fixup value), attackers will not 60 W e3 . Each of these is connected to one or more of Xq 

be able to perform unauthorized key updates with a high through X 127 (labeled 835), where the specific choice of 

enough success rate to produce a commercially-viable connections is made by the PAFG. The remaining inputs to 

attack. Note: another embodiment of group targeting is XOR gates 840 are connected to randomly-selected bits 

described below with respect to FIGS. 10 and 11. Many from C 0 . . . C 15 , Kq . . . K 127 , and/or . . . U 127 . The XOR 

variants of the embodiment shown in FIG. 7 are also 65 gate outputs 850 (labeled Y 0 through Y 63 ) are connected by 

possible; see (for example) the section below entitled the PAFG to inputs randomly selected from Z 0 through Z 127 

" Variations." (labeled 855). The remaining inputs to the final set of NAND 
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gates 860 are selected from among C 0 . . . C J5 , Kq . . . K 127 , devices that contain the inverse function are operated by the 

\J 1 . . . U 127 , W 0 . . . W 63 , and Y 0 . . . Y 63 . Finally, the outputs content provider, they can be stored in physically-secure 

of NAND gates 860 and the original 128-bit shift register's locations. As a result, tamper- resistance is not required, so 

left-hand bit 805 are XORed together by XOR gates 870, the inverse may (for example) be implemented in software 

producing a single-bit result 880. The 128-bit shift register 5 or in programmable integrated circuits (such as FPGAs). 

800 is then shifted left one position (i.e., storing the contents n is possible for the PAFG to be configurable to produce 

of bit 1 into bit 0, bit 2 into bit 1, but 127 into bit 126, etc.) 0Ut p U t tailored to the implementation. For example, output 

and the single result bit 880 is placed in bit position 127. To can be tailored to accommodate different circuit description 

transform an input block, the operation shown in FIG. 8 is languages, circuit sizes, layouts, logic gate (or logic cell) 

performed repeatedly with a corresponding increment or 10 types, and wiring limitations. For example, in one 

update to clock counter 804 after each operation. The key embodiment, the PAFG is configured to produce a circuit of 

802 can also be updated, for example by transforming it with variable size so that a system designer can select an output 

a maximal-length shift register. The number of iterations circuit whose size corresponds to the amount of space 

performed is implementation-specific and may be variable, available on a chip's die 

depending on factors such as performance requirements and 15 Qne major advant of the pAFG architecture is that it 

the quality of the mixing function. can produce cifcuits ^ afe difficuh {Q reverse engineer 

Of course, the implementation illustrated in FIG. 8 is wh il e still allowing open cryptographic evaluation. The 

substantially simplified, since a real hardware implementa- paFG itself does not need to contain any secrets because it 

tion could be comprised of many thousands of gates. In constructs the output circuit using interconnects and other 

addition, the exemplary embodiment uses only two types of 20 desigQ parameters generated using a random source. As a 

gates (XOR and NAND), but other logic operations may be resu lt, the PAFG design and implementation can be 

employed in addition or instead. Additional inputs may also analyzed^or even published for open review— to assess 

be incorporated into the computation or some inputs may be whether there is any significant chance that the PAFG will 

omitted (such as the counter C). generate a cryptographically insecure function. The PAFG 

FIG. 8 uses a 128 bit to 1 bit basic transformation 25 architecture thus allows for unrestricted use of outside 

function, but other embodiments may also use other con- review and does not require burdensome security precau- 

struclions for the transformation. For example, the con- tions on the reviewers typically required when using obfus- 

structed function can have a Feistel structure (which may be cated algorithms. The PAFG thus provides resistance to 

balanced or unbalanced). Constructions without the regular- reverse engineering without relying on security by obscurity, 

ity of a Feistel or shift register may also be used (and may 30 (Of course, PAFG implementations that do not use good 

be advantageous since attacks such as microprobing the random sources can be constructed as well, but are not 

circuit for computation intermediates can made more dififi- preferred.) 
cult if there are a large number of interrelated internal 

intermediates). Even though it is usually advantageous that An Exemplary Simplified Architecture 

the pseudoasymmetric function be a permutation, some 35 , c . ~ t „ , ... ... 

, r ' , , \, t \ , . 4 Ine complexity of the CryptoFirewall described with 

embodiments may produce functions that are not strict , , r?/™ 4 *u u -» u 1 1 r 

awl i_ iL • « . . , . ™^ 0 regard to HGS. 2 through 7 can be reduced significantly, 

permutations. Although the embodiment shown in FIG. 8 -Jf. , . , . c , ... . 

r , 4 b t / * , , . , . . , , * This section outlines one such simplified architecture that 

uses two input parameters (a data block and a key block), „, • ♦ • .u 1 . j r 

, *, , K 4 . ■ .1 i- ■ 1 m a intams the general memory protection and security fe a - 

alternate embodiments can combine these, eliminate the key, , T # . c t ... / r t . . - . „. J .. 

. . . . . 3 40 tures. In the first embodiment presented, the CryptoFirewall 

or include additional parameter values. . , . , t . r . * V. * . 

r supports only prepaid rights, leaving other security features 

In some CryptoFirewall embodiments it is advantageous ( such as post-payment purchase auditing) to be enforced by 

to use multiple pseudoasymmetric functions to ensure that lhe (less secure) , CR A disadvantage is that attackers who 

outputs from one operation cannot be used to attack other compromise the ICP could potentially erase post-payment 

operations. To reduce the size of an implementation, it is 45 audit rccordSi bul an advantage is that the CryptoFirewall 

possible to share many or all logic components between implementation is significantly simplified, 

these functions. A single transformation circuit can provide nG 9 di {he ion of aQ { c t0 _ 

multip e operations if a transformation selector is used. For Hrewall ^ { im lements id ri hts but caQ be easiI 

example, a 3-bit function identifier placed m the most £xtended tQ [6 ^ ^ Donvolatile [ 

significant 8 bits of the counter in C 0 C, shown m FIG. 5Q ^ m (he c toFirewall contains a device 

8 could provide for eight separate transformation operations. key (c^p^y) well ,3 memory locatioQS for storing 

llie output of the PAFG can have any form, but is prepaid rights keys. At step 900, the CryptoFirewall receives 

typically a circuit representation that can be included a key address from the ICP and makes sure that the address 

directly in an application-specific integrated circuit (ASIC). corresponds to a valid key offset in the protected memory. 

For example, standard languages (such as Verilog and 5S (For example, if keys are 8 bytes long, zeroing the three least 

VHDL) for designing integrated circuits may be used as the significant address bits ensures that the base address is not 

output format. Additional automated or manual modification mis-aligned.) At step 910, the CryptoFirewall loads from the 

of the output (such as adding basic structures around the protected memory the data stored at the specified address 

function, optimizing the operation, etc.) can be performed if and p i aces lne xa a ^ cy reg i s t cr . At step 920, the 

required. 60 CryptoFirewall receives a data block from the ICP. At step 

In a preferred embodiment, the PAFG also outputs a 930, the CryptoFirewall uses the key read at step 910 with 

circuit definition for the inverse function in addition to the a pseudoasymmetric function to transform the data block 

"forward" function. A hardware implementation of the for- obtained at step 920. At step 940, the CryptoFirewall tests 

ward function is distributed to untrusted parties, for example whether if the address read at step 900 corresponds to the 

in the CryptoFirewall, while the inverse is typically man- 65 location of the CHI P_KEY in the protected memory. If not, 

aged securely by the content provider(s) and used to prepare at step 950, the CryptoFirewall outputs the pseudoasymmet- 

content, REMs, KDMs, etc. for distribution. Because the ric transformation result to the ICP and concludes. (Results 
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produced using keys other than CHIP_KEY — i.e., rights 
keys — are used to derive content decryption keys, so the 
results are not stored. Transformations protected with the 
CHIP„KEY are used to add new rights keys to the protected 
memory.) Otherwise, at step 960, the CryptoFirewall reads 5 
a second address from the ICR At step 970, the CryptoFire- 
wall optionally tests whether the result of the transformation 
is valid for writing at the address specified at step 960 to 
prevent attackers from inappropriately modifying values in 
the protected memory. This check is primarily required to 3Q 
prevent over-writing of CHIP_KEY values stored in 3 
update able memory. (For example, before allowing a write 
to the CHIP_KEY, the CryptoFirewall can verify that the 
result of the pseudoasym metric transformation has a pre- 
defined characteristic — for example, that its first 56 bits 
equal "10" repeated 28 times.) Alternatively or in addition, 
the CryptoFirewall should verify that the destination address 
value is appropriate (e.g., not pointing to the CHIP_KEY), 
If the CryptoFirewall determines at step 970 that the write is 
authorized, it performs the write at step 980. 

The embodiment of FIG. 9 has the advantage of being 
very simple, and hence relatively easy to implement and test, 
but relegates some security tasks (particularly tracking of 
post-paid purchases) to the I CP. As a result, attackers who 
compromise the ICP could tamper with post-payment audit- 25 
ing. As noted, the risk of such attacks can be mitigated by 
requiring the presence of a prepaid rights key to access 
post-paid content. This prepaid rights key can be updated 
when an on-line audit completes successfully, thereby pre- 
venting devices that have not been audited recently from 3Q 
accessing post-paid content. (Using a "hacked" CRU to 
perform an audit is relatively risky, particularly if audits 
suggesting illegal activity can be traced back to specific 
users through Internet IP addresses, Caller ID/ANI, etc. As 
a result, the actual and perceived risk can be high enough 35 
that attacks on the post-payment audit data will not present 
a serious piracy threat.) 

With a modest addition of complexity, the FIG. 9 archi- 
tecture can be expanded to include support for post-payment 
purchases. At step 940, the CryptoFirewall checks whether 40 
the address points to the unique chip-specific key or a 
post-payment authorization key. If neither, processing con- 
tinues at step 950, as shown. Otherwise, step 960 is per- 
formed normally then step 970 is performed as follows; 

(a) If the key loaded at step 910 is the post-payment 45 
authorization key then the CryptoFirewall tests whether 
the address received at step 960 corresponds to an 
empty post-paid rights slot. If it does, the transforma- 
tion result is written at step 980. (This corresponds to 
a normal addition of a post-paid rights key.) Otherwise, 50 
if the address does not correspond to a post-paid rights 
slot or if the slot is not empty, no write is performed. 

(b) If the key loaded at step 910 is the chip-specific key 
AND the address received at step 960 corresponds to a 
prepaid rights slot, then the transformation result is 55 
written. (This corresponds to a normal addition of a 
pre-paid rights key.) The CryptoFirewall can optionally 
allow replacement of the post -payment authorization 
key as well (i.e., if the address received at step 960 
corresponds to the post-payment authorization key). 60 

(c) If the key loaded at step 910 is the chip-specific key 
AND the address received at sicp 960 corresponds to a 
post-paid rights slot, then the CryptoFirewall tests 
whether the transformation result from step 930 
matches the value of the post-paid rights slot. If there tis 
is a match, the memory slot is cleared." Otherwise, no 
write is performed. 
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Post-paid rights slots can be designated as empty if all bits 
are cleared (or set). In this case, the update processes used 
in (b) and (c) above require only writing (or clearing) bits in 
the protected memory. If the protected memory uses a 
technology such as EEPROM where bit clearing and bit 
setting operations are performed separately, the post- 
payment addition process can be implemented so that pur- 
chasing and clearing each use one type of bit operation. 

To audit post-paid purchases, the content provider can (for 
example) use the standard key generation process and pro- 
vide a random challenge for the data block at step 920. The 
output from step 950 is compared with expected values for 
post-paid purchase keys to identify the key in the protected 
memory. (Alternatively or in addition, purchase data can be 
obtained from the ICP or additional logic can be provided in 
the CryptoFirewall for audits.) Because the audit clearing 
process is secured using a chip-specific key, attacks that 
modify audit data will have limited effectiveness. In 
particular, audit records will only be cleared if the content 
provider has correct audit data. As a result, the number of 
purchases that can be performed without paying is limited 
by the number of post-payment audit record slots in the 
CryptoFirewall. For risk management, the content provider 
can initially ship CRUs with only a few empty slots, then 
gradually clear slots as customers establish their trustwor- 
thiness. 

Another Exemplary Simplified Architecture 

This section outlines a simplified CryptoFirewall archi- 
tecture that only provides security for pre-paid content 
purchases. This embodiment has the advantage of being able 
to use volatile memory instead of writeable nonvolatile 
memory behind the CryptoFirewall, Because volatile 
memory is often easier to implement (e.g., because only 
standard logic components are required), manufacturing and 
design costs can be reduced. 

Embodiments of the present invention that use only 
volatile memory require access to a unique parameter that 
cannot be replaced by attackers. This unique parameter is 
preferably embedded into the circuit, for example using 
ROM or blown fuses. Techniques for embedding unique 
parameters in chips are known in the background art. For 
example, U.S. Pat. No. 5,799,080 to Padmanabhan et al. 
describes techniques for embedding serial numbers and 
cryptographic keys in integrated circuits. 

FIG. 10 shows an exemplary CryptoFirewall embodiment 
using a small (for example, 64-bit) volatile protected 
memory and using batch keys to minimize the bandwidth 
required for REMs, During manufacture (i.e., prior to the 
process of FIG. 10), the CryptoFirewall is personalized by 
permanently embedding a 64-bit BATCH_KEY and a 6-bit 
BATCH_OFFSET. For example, 64 pairs of fuses may be 
used to store a 64-bit BATCH_JCEY where the personal- 
ization process blows one fuse of each pair. To ensure that 
attackers will not benefit from attacks or manufacturing 
defects that only connect or only blow fuses, self-test logic 
can be incorporated to ensure that exactly one fuse of each 
pair is blown. (Of course, other self-test or verification 
techniques can also be used. Multiple fuses can also be used 
to help obfuscate the value of the key bits, for example by 
making each bit or group of bits the XOR or hash of many 
fuses.) It is strongly preferable although not strictly required 
that the combination of BATCH_KEY and BATCH_ 
OFFSET be unique per CryptoFirewall. 

In FIG. 10 at step 1000, the interface control processor 
(ICP) loads a 64-bit key mask value into an externally- 
accessible 64-bit register in the CryptoFirewall. 
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At step 1010, the CryptoFirewall verifies that the bit in the ally combines BATCH_KEY 1145 (which is the same as 

key mask corresponding to its BATCH„OFFSET is set. For BATCH_KEY 1120) with the protected memory contents 

example, if the CryptoFirewall's embedded BATCH_ and provides the result as a key to pseudo asymmetric 

OFFSET is binary 101110 (46 decimal), the CryptoFirewall transformation 1155, Combination logic 1140 is optional; 

will verify that bit 46 of the key mask value is set and, if not, 5 for example, the output of pseudo asymmetric transformation 

the processing terminates. In an alternate embodiment, the 1130 can be used directly to key Uauaiormation 1155. Note 

CryptoFirewall sets the bit corresponding to the BATCH_ that transformation 1155 does not need to be invertable. For 

OFFSET if it is not already set. (Of course, alternate example, a keyed hash function such as HM AC can be used 

embodiments can use encodings other than binary "1" for instead of a pseudoasymmetric function, 

valid, use other testing processes, decrypt or otherwise 10 Encrypted content decryption key 1150 is transformed by 

process the key mask before testing, corrupt the key mask if pseudoasymmetric transformation 1155, yielding content 

the BATCH__OFFSET bit is not set, use batch offsets that decryption key 1160. (In an alternate embodiment of the 

involve multiple bits in the key mask, use multiple key invention where the CryptoFirewall directly decrypts the 

masks, etc.) content itself, the content itself or a portion of the content 

At step 1020, the CryptoFirewall copies the validated key 35 mav be supplied instead of encrypted content decryption key 

mask value from the input register to the CryptoFirewall's 1150.) Note that further processing on the content decryp- 

protected memory. The CryptoFirewall can optionally per- tion key 1160 can be performed (e.g., by the ICP, playback 

form some cryptographic processing of the value during this device, etc.) before the actual content decryption is per- 

copying. formed. 

At step 1030, the ICP loads a 64-bit encrypted rights key 20 To ensure that operations are performed in the correct 

into the CryptoFirewall's externally-accessible register. order, the CryptoFirewall should keep track of the current 

Under normal operation, this key corresponds to some state in the transaction processing. For example, the Crypto- 

content a user wishes to decode. Encrypted rights keys are Firewall should not allow reading of any results until it has 

normally obtained by the ICP from a REM that was trans- completed processing, 

milled by the content provider. Because rights keys may last 25 To distr ibute a rights key, the content provider first 

a considerable period of time (e.g., 30 days for a month-long chooses the value of the rights key and identifies one or more 

subscription to a cable TV channel), encrypted rights key CRTJs iQ a batCQ that win be authorized receive the key . 

values can be cached (with the corresponding key mask) in Next> the content provider constructs a key mask by setting 

nonvolatile memory external to the CryptoFirewall. the 5its corresponding to the authorized CRUs'BATCH_ 

At step 1040, the CryptoFirewall applies a pseudoasym- OFFSET values. From the mask and the BATCH__KEY, the 

metric transformation to the encrypted rights key. The content provider can assemble the output of logic 1115. 

pseudoasymmetric transformation is keyed using the XOR Using the inverse of pseudoasymmetric transformation 1130 

of the protected memory contents (i.e., the verified key mask (e.g., as prepared by the PAFG) with the output of logic 1115 

value) and the BATCH„KEY loaded during manufacture. a s the key, the content provider can compute encrypted 

The transformation result is stored in the protected memory, rights key 1125 for distribution. 

replacing the key mask. If bandwidt h for key distribution is not limited, the batch 

At step 1050, the ICP stores an encrypted content decryp- key capability included in FIGS. 10 and 11 is not required, 

tion key in the CryptoFirewairs externally-accessible reg- Instead, device-specific keys can be used and (for example) 

ister. The encrypted content decryption key is typically 40 supplied directly into the pseudoasymmetric transformation 

obtained from a KDM distributed by the content provider in FIG. 10 at step 1040. As a result, the CryptoFirewall is 

with the content to be decoded. somewhat simpler but separate encrypted rights keys need to 

At step 1060, the ICP applies a pseudoasymmetric trans- be distributed for each user. CryptoFirewall architectures 

formation to the encrypted content decryption key. As in step can also include both device -specific keys and shared keys. 

1040, the pseudoasymmetric transformation is keyed using 45 The architecture of FIGS. 10 and 1 prevents a variety of 

the XOR of the protected memory contents (i.e., the attacks that involve submitting key masks and/or encrypted 

decrypted rights key) and the BATCH_KEY loaded during rights keys to unauthorized CRUs. For example, if the key 

manufacture. The transformation result is stored in the m ask value is modified in any way (e.g., by setting the bit 

externally-accessible register, where it can be read by the for an unauthorized CryptoFirewall in the batch), the input 

ICP at step 1070 and used to decode the content. 50 to pseudoasymmetric transformation 1130 will be modified, 

FIG. 11 diagrams the same content decryption key com- preventing the correct decryption of encrypted rights key 

putation process. Key mask 1100 identifies which Crypto- 1125. Similarly, if an encrypted rights key from a different 

Firewalls in a batch are authorized to decrypt an encrypted batch is submitted, the rights key will also fail to decrypt 

rights key 1125. (Encrypted rights keys are distributed with correctly. 

an associated key mask.) The key mask is checked by key 55 Many variant embodiments are possible. For example, 

mask validator 1105, which verifies that the CryptoFirewall other combination processes (such as encryption, 

is among the authorized devices in the batch as specified by pseudoasymmetric transformations, modular addition, etc.) 

the key mask. If valid, a representation of key mask 1100 is can be substituted for XOR logic 1115 or logic 1140 in FIG. 

stored in protected memory 1110. (If it is invalid, the value 11. Combination function 1115 can be omitted altogether or 

is not stored or it is stored in corrupted form.) Combination 60 replaced with concatenation if pseudoasymmetric transfor- 

logic 1115 XORs (or otherwise combines) protected mation 1140 takes a large enough key. Specified parameter 

memory contents 1110 with BATCH_KEY 1120 and pro- sizes are exemplary. For example, 160-bit keys can be used 

vides the result as a key to pseudoasymmetric function 1130. to provide better security than 64-bit keys against some 

The data input to pseudoasymmetric transformation 1130 attacks. Larger key mask sizes can increase efficiency of 

is encrypted rights key 1125, which is transformed and the 65 bandwidth use. Operations can be reordered and additional 

result is stored in protected memory 1135 (which is the same transformations can be added. (Additional variations are 

as protected memory 1110). Combination logic 1140 option- described below in the section entitled "Variations") 
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Physical Implementations 

The physical implementation of the CRU can have several 
forms. A preferred implementation involves comhining the 
interface control processor (as well as its memory) with the 
CryptoFirewall and protected memory on a single chip, 
which is then placed in a smartcard or PCMCIA card (PC 
card). Because the CryptoFirewall security model does not 
assume that the interface control processor (ICP) is com- 
pletely secure, the CryptoFirewall should be implemented in 
hardware separate from the ICP, for example as a separate 
circuit on the same integrated circuit. 

The protected memory used by the CryptoFirewall can be 
separate from, or part of, nonvolatile and/or volatile memory 
accessible by the I CU. If the CryptoFirewall and ICP share 
memory regions, the CryptoFirewall is responsible for 
ensuring that the ICP cannot inappropriately access the 
protected memory without the required cryptographic trans- 
formations. In particular, the CryptoFirewall should inter- 
cept and process accesses to protected regions while allow- 
ing other accesses to pass through it. 

The CryptoFirewall architecture can be combined with 
hardware and chip card security features known in the 
background art. For example, detectors can be included to 
reset the device if unusual operating conditions (such as 
high/low operating voltage, high/low temperature, high/low/ 
irregular clock signals, radiation, etc.) are encountered. 
Tamper-resistant coatings, chip obfuscation techniques, con- 
ventional memory encryption techniques, error detection/ 
correction logic, intrusion detectors, etc. can also be used. If 
potential attacks are detected, the CryptoFirewall can (for 
example) erase any internal registers, reset itself, reset the 
ICP, and optionally even erase the protected memory. 

The CryptoFirewall may be implemented using dedicated 
hardware (discrete logic) or using a separate microprocessor. 
In one preferred embodiment, two microprocessors (each 
with its own RAM, ROM, and EEPROM) are integrated 
onto a single chip, which is then embedded in smartcard 
packaging. One microprocessor serves as the ICP and com- 
municates with the second microprocessor which is the 
CryptoFirewall. Although a dual-microprocessor CRU is 
somewhat more expensive to manufacture than the single- 
microprocessor CRUs in use today, it has the important 
advantage that the inner microprocessor (CryptoFirewall) is 
shielded from many attacks by the outer microprocessor. 

The clock signal used to drive the CryptoFirewall can be 
taken from (or derived from) an external clock interface, 
generated internally, or supplied by the ICP. If present, 
clocks derived internally by the EEPROM circuit for timing 
write operations can also be used. External clocks should be 
used with caution to ensure that disruptions in the clock 
signal will not cause computation errors that could be used 
to attack the circuit. Clock dividers and multipliers can also 
be used. 

The CRU of the present invention can be implemented in 
a wide variety of forms. For example, components 210, 270, 
280, and 225 in FIG. 2 can be physically located in the same 
unit or can be individual components that communicate with 
each other. The entire CRU can be implemented in a single 
chip or using multiple chips enclosed in a tamper- resist ant 
packaging. (Single chips themselves are sufficiently tamper 
resistant for many systems, although features such as tamper 
resistant coatings can be included if desired.) 

In one preferred embodiment, the entire CRU is imple- 
mented in a single smartcard. Alternatively, the CRU can be 
a PCMCIA card. The CRU can also be a pari of ihe playback 
device and can be integrated with other portions of the 
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playback system such as bulk decryption, content 
decompression, and/or output. For security reasons, the 
CryptoFirewall needs to be an independent circuit from the 
interface control processor, but can have any form (e.g., a 

5 hard-wired circuit, an independent microprocessor, etc.) 
The CRU can be integrated into the playback device, 
providing the benefit of making it more difficult for attackers 
to capture or insert content decryption keys exchanged 
between the playback device and the CRU. As a result, some 

10 key redistribution attacks can be prevented. (For content 
whose value is not time-sensitive or for systems operating in 
jurisdictions where anti-piracy laws are unavailable or 
unenforced, such attacks are of particular concern. Key 
redistribution attacks may also become more dangerous as 

35 computer networks such as the Internet can provide attack- 
ers with new methods for redistributing keys.) Physical 
integration of the CRU with the playback device has the 
disadvantage of making it more difficult to replace the CRU 
if an attack does occur. Alternatively or in addition, the 

20 content provider can withhold key derivation messages until 
they are actually required by the playback device to mini- 
mize the amount of time available for attackers to redistrib- 
ute keys. Playback devices can also halt if keys are not 
received in a timely fashion. 

25 Preparing Content 

Digital content is usually distributed in compressed form. 
Processes for creating, formatting, and compressing content 
of different types are well known in the background art. In 
30 most situations, content is encrypted after it is compressed, 
since encrypted material does not compress well. 
Occasionally, however, compression and encryption are 
combined or simple encryption is applied before compres- 
sion. 

35 The key(s) used to encrypt the content are carried in the 
content's KDMs, which are secured with rights keys dis- 
tributed in REMs sent to authorized users. KDMs can 
specify combinations of rights keys required to access 
content. For example, if two rights keys should be required 

40 to access a particular block of content, the content provider 
can first generate an encrypted key block (e.g., correspond- 
ing to encrypted content decryption key 1150 in FIG. 11). 
The content provider then constructs a KDM instructing the 
ICP to (for example) process the encrypted content decry p- 

45 tion key twice (each time using the process described with 
respect to FIG. 10) and combine the results (e.g., by XORing 
them together) to produce the decrypted content decryption 
key. The content provider also computes the content decryp- 
tion key and uses it to encrypt the content. Next, the content 

50 provider typically associates KDMs with the content, for 
example by interspersing KDMs at appropriate places in the 
content or by making other arrangements for the KDMs to 
be communicated to playback devices. REMs can also be 
added if they are distributed with the content. Finally, the 

55 content is sent to end users. 

In an alternative embodiment, the content provider can 
begin by selecting a content decryption key. This key may be 
(but is not required to be) random. The content provider then 
uses the inverse of the CryptoFirewall pseudoasym metric 

60 function to encrypt the content decryption key with a first 
rights key. If a second rights key is also required to access 
the content, the content provider can then use a second rights 
key to encrypt the content decryption key. The content 
provider then packages the encrypted CDK into a KDM for 

65 distribution and encrypts the content. 

Content providers can also broadcast "fixup" values in 
KDMs that can enable CRUs with any of several rights keys 
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to decode the content. In such cases, the ICP typically 
locates the address of a valid rights key, uses the Crypto- 
Firewall to process an encrypted rights key, and XORs (or 
otherwise combines) the CryptoFirewall result with the key 
fixup value to derive the actual content decryption key. For 
example, if any of three rights keys (Kl, K2, and K3) should 
allow access to some content and the CryptoFirewall key 
derivation process is denoted F(K i ,X) where X is a data 
block and K, is a BLOCK__KEY, the content provider can 
choose F(K X ,X) as the content decryption key. The KDM 
can then include F(K lt X) XOR F(l4, X) to enable CRUs 
with only to derive the content decryption key. Similarly, 
including F(K Jf X) XOR F^, X) allows CRUs with K 3 to 
decode the content. This "either/or" rights key selection 
operation can be combined with the "and" operation 
described above to allow the content provider to establish 
sophisticated rules as to which CRUs can decode content. 
Fixups can also be used to produce compatibility between 
CRUs of different types (e.g., during periods where CRUs 
are being replaced and two versions are supported). Because 
the key combination rules are secured cryptographically, the 
KDM parsing and key construction processes can be imple- 
mented in the ICP. 

It is possible (and often advantageous) to change content 
decryption keys frequently, for example by requiring a new 
KDM and a new key for each one-second or one-minute 
block of content. If desired, blocks can be protected with 
different combinations of rights keys. To reduce the latency 
experienced by users when they begin to decode some 
content, the content provider can make key changes coincide 
with places where the decompression algorithm can resyn- 
chronize. For example, with MPEG-2 compressed video, 
key changes can be made to coincide with I pictures. 

Comments and Considerations 

Under the architecture outlined in FIG. 2, the system 
remains robust even if the ICP and its RAM, ROM, and 
EEPROM are compromised. This is an extremely important 
feature of the present design, since these components of a 
chip are particularly vulnerable to both invasive and non- 
invasive attacks. The CryptoFirewall controls the addition of 
rights keys to the protected memory and thereby prevents 
information obtained from one CRU from providing attack- 
ers with the ability to add rights keys to other CRUs without 
breaking the cryptography or performing an invasive attack. 
Even if rights keys are compromised, attackers cannot insert 
them behind the CryptoFirewall. 

In order to compromise the system, the attacker must do 
one of two things: either duplicate the functionality of the 
CryptoFirewall \s pseudoasymmetric transformation or gain 
the ability to use a CRU's CryptoFirewall for unauthorized 
purposes. The former attack is prevented by making it 
difficult to reverse engineer the randomized transformation 
circuit. In addition, for large deployments, groups of CRUs 
can contain different pseudoasymmetric functions to reduce 
the consequences of a successful reverse engineering attack. 
Use of group -specific keys (such as BATCH_KEY values) 
to broadcast periodic rights keys (such as hourly or daily 
keys) can also reduce the consequences of many reverse 
engineering attacks. 

If the CryptoFirewall is implemented properly, a 
physically-invasive attack should be required to gain unau- 
thorized control over the protected memory. If the CRU is 
implemented as a single-chip device (such as a smarlcard) 
with reasonable physical security measures, physically- 
invasive attacks pose relatively little risk of being performed 
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on a large number of devices because, even after such an 
attack has been identified, attackers still have to perform the 
time-consuming and expensive process of decapping, 
modifying, and remounting each target chip. These tech- 
niques also require expensive equipment and have a fairly 
high chance of damaging the target chip. As a result, most 
systems will not experience significant amounts of piracy 
even if attackers discover a physically-invasive attack that 
breaches the CryptoFirewall. 

The architecture does assume that some devices will be 
attacked invasively, and therefore minimizes the usefulness 
of the keys and other data that could be obtained. In 
particular, a physically invasive attack will potentially pro- 
vide an attacker with the ability to read from and/or write to 
the protected memory of the compromised device. Embed- 
ded keys (such as BATCH_KEY or BATCH_OFFSET) 
could be read and/or modified. Simply reading the protected 
memory contents provides no particular value, since the 
keys stored in the memory are not useful without the 
algorithms implemented in the cryptographic unit. The abil- 
ity to write to the memory can, however, enable some 
significant attacks, since it then becomes possible for the 
attacker to delete post-payment records, insert new autho- 
rization keys, or modify batch offsets. A properly- 
functioning CryptoFirewall is still required, however, to 
process these values into content decryption keys. As a 
result, the attacker's work modifying one chip can yield one 
fully-functional pirate device, but should not lead to a 
general attack that can be marketed on a wide scale. 

Variations 

This section presents several examples of modified 
embodiments of the present invention, and other variants 
will be evident to one of ordinary skill in the art. 

The present invention may be used in conjunction with 
other content protection mechanisms. Content can be water- 
marked to trace compromises, identify copyright owners, 
etc. Non-cryptographic security measures can be added in 
the CRU, playback device, etc. and can help by increasing 
the effort required for an attack. Tamper evidence (in addi- 
tion to tamper resistance) in the CRU can help to discourage 
attacks and prosecute pirates. 

In addition to providing a "positive" benefit of adding 
rights, REMs can also have negative effects such as dis- 
abling a CRU by deleting or corrupting a rights key. Such 
negative effects can be implemented by the ICP and/or by 
the CryptoFirewall. To prevent attackers from blocking all 
REMs, the content provider can combine KDMs and REMs 
or make them indistinguishable (e.g., by encrypting them). 

Data blocks in KDMs (e.g., such as the data block 
received by the CryptoFirewall in FIG. 9 at step 920) can 
have additional meaning to the ICP or CryptoFirewall, such 
as a code update or self -check. The content provider can also 
specify to the ICP that it should supply a portion of the ICP's 
nonvolatile memory as the encrypted CDK or specify other 
methods for deriving such values. If KDMs do not need to 
carry new information from the content provider, they can be 
generated by the CRU, playback device, etc. For example, a 
timer can be used to generate unique values for the data 
block used for content decryption. (Implementers of such 
embodiments may need to be careful, however, to prevent 
attackers from generating and distributing content decryp- 
tion keys before the content is actually broadcast.) 

Ttie process performed to derive the content decryption 
key can include multiple rights keys and/or transformations. 
For example, multiple iterations of the process shown in 
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FIG. 5 can be performed and the results can be XORed, where the data itself must be stored and protected in the 

added, concatenated, hashed, or otherwise combined. (The CRU.) Volatile protected memory can also be implemented 

I CP can manage this process.) The output from a first using a variety of techniques, including registers imple- 

iteration can be used as the input to subsequent iteration(s). mented using standard logic, SRAM, DRAM, etc. 

A content provider can, for example, require that CRUs 5 Although it is strongly preferable that values stored in the 

contain multiple rights keys to access some conieni. For protected memory be cryptographic keys of sufficient length 

example, a block of content might require a general rights and quality to prevent attacks such as exhaustive search, it 

key that is updated frequently (e.g., hourly), a stream- is possible to store shorter values. In one extreme case, 

specific rights key, a post-payment purchase authorization individual bit flags that correspond to access rights can be 

key, a post-payment audit key (indicating that a successful 10 stored in the protected memory. Valid REMs cause the 

audit was performed recently), a region key (to enforce Crypto Firewall to set and/or clear rights bits in the protected 

sports programming blackouts or other geographic memory. When producing content decryption keys, the 

restrictions), and/or a premium service rights key. Crypto Firewall tests the value(s) of rights bits (or incorpo- 

The ICP can be involved in cryptographic computations. rates tnese bit values in the cryptographic transformations) 

For sophisticated KDMs, the ICP can identify and extract the 15 so mal vaud content decryption keys are only produced if the 

components usable by the CryptoFirewall, manage I/O with appropriate bit(s) are set. Such embodiments, although 

the playback device and CryptoFirewall, and combine possible, involve more risk because invasive attacks will 

results to produce valid content decryption keys. The ICP tencl t0 have more severe consequences, 

can also perform additional cryptographic processing on The components of the CRU do not need to be connected 

REMs and/or CDKs. Although the CryptoFirewall may be 20 by a bus. In fact, eliminating the bus and directly connecting 

designed with the assumption that the ICP is not a trusted components can have the advantage of increasing the effort 

part of the system, it does not cause any harm to also include required for physically- invasive attacks as buses can be 

security in the ICP so that attackers will not succeed unless attacked using (for example) microprobing techniques, 

they compromise both. Some security-related operations CRUs can contain any number of batch keys or device 

(such as local blackouts of sporting events) are relatively keys . A]s0) batcn keys do not need to be ass j gried sequen- 

unlikely to be the focus of concerted attacks and are difficult ua lly during the manufacturing process. (In fact, shuffling 

to implement in dedicated circuitry, and therefore can be key assignment can be beneficial to make it more difficult for 

performed by the ICP. attackers to obtain cards with identical batch keys.) Batch 

Not all data needs to be protected to the maximum 3Q keys (and other keys) also do not need to be static; they can 

possible level of security. Occasional deletions, for example, be replaced or updated using, for example, a key update 

are usually sufficiently irritating to prevent attacks that do process such as the one described with respect to FIG. 7. By 

not decode all of the content. Because compression tech- including keys for multiple independent batches in each 

niques can make even single bit errors disrupt playback, CRU, the consequences of an attack against a single CRU 

strong protection over just a few percent (or less) of the total 35 (or small number of CRUs) can be minimized since future 

content can be sufficient. As a result, adequate security can REMs and KDMs can be protected using keys that were not 

often be obtained despite challenging bandwidth or perfor- in the compromised device(s). If a clone is produced, it is 

mance limits on the CRU or decryption system. Different possible to replace legitimate cards in the compromised 

portions of the content can also use different levels of device's batch then discontinue sending REMs for that 

protection. For example, relatively weak securily can be ^ batch. 

applied to most of the content but much stronger protection Techniques such as those described in "Tracing Traitors" 

can be applied to a small fraction of the material. by Benny Chor, Amos Fiat, and Mom Maor (Advances in 

Content providers should change rights keys periodically Cryptology — Crypto '94, Springer- Verlag, August 1994, pp. 

to ensure that users who have lost their authorization cannot 257-270) can be used to identify the source of rebroadcast 

access content. For example, if a user terminates a 45 keys. The CRU can also encrypt content decryption keys, for 

subscription, the CRU may continue to operate unless the example using an RSA public key corresponding to the 

rights key is deleted/disabled or mechanisms outside the playback device's private key or, preferably, using a unique 

CryptoFirewall disable access. Content providers can limit symmetric key shared between the CRU and the playback 

the maximum duration of such use by making rights keys device added during manufacturing. Such techniques can 

expire periodically (e.g., hourly, daily, weekly, monthly, 50 help prevent key redistribution attacks that involve using 

annually, etc.) To ensure that key changeovers do not disrupt keys produced by one CRU in many playback devices. If the 

legitimate viewers, new rights keys can be distributed before CRU has sufficient I/O bandwidth and computational speed, 

the old ones are discontinued. During the changeover period, it can decode the content itself. 

content can also he broadcast with KDMs that can operate The pseudoasymmetric transformations can be imple- 

using both the old rights key and the new one. An additional 55 me nted using (or replaced with) a variety of cryptographic 

option is to queue the REM that updates the key until the key operations. Methods for building randomly-constructed 

change is required. (Such queuing can be done by the i og i c operations are described with respect to FIG. 8, but 

playback device, ICP, etc.) other constructions can be used instead. For example, stan- 

The memory technology used for nonvolatile protected dard algorithms (such as Triple DES), one-way hash 

memory does not need to be conventional EEPROM. For 60 operations, etc. can be substituted. It is also possible to use 

example, PROM, flash memory, battery-backed RAM, a combination of functions, such as Triple DES with ran- 

FeRAM, etc. all provide nonvolatile storage. Embodiments domized pre- and/or post-processing to ensure that the 

can even use hard drives or other media-based storage cryptographic security is demonstrably as robust as Triple 

systems, although such approaches are generally infeasible DES. Pseudoasymmetric functions can also be replaced by 

due to their high cost and the difficulty of adding sufficient 65 true asymmetric functions, which can provide better security 

physical security. (Variants where a hard drive, or a portion but require longer messages and take larger circuits to 

of the hard drive, is protected can be useful in environments implement (e.g., increasing the cost of the CryptoFirewall). 
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Although it is generally simplest to have the interface from the pending buffer when the device is reset. Write 

control processor determine which memory addresses to use operations can be verified to detect errors. Checksums or 

when storing and using rights keys, addresses can also be other verification fields can be included in stored data to 

chosen by the CryptoFirewali, by the content provider, by detect memory corruption. 

the playback device, etc. 5 All of the foregoing illustrates exemplary embodiments 

If errors occur in the CRU or CryptoFirewali, a failure and applications of the invention, from which related 

counter can be incremented and, if the failure counter variations, enhancements and modifications will be apparent 

reaches a threshold value, the CRU may trigger an audit or without departing from the spirit and scope of the invention, 

cease to work. Examples of failures include tom operations Therefore, the invention should not be limited to the fore- 

(i.e., where processing is interrupted, for example due to a ]0 going disclosure, but rather construed by the claims 

power loss), invalid commands (e.g., where invalid appended hereto, 

addresses are supplied), attempts to perform excessive num- We claim: 

bers of transactions, and incorrect cryptographic parameters 1. A tamper-resistant device for regulating access to 

(such as failed attempts to clear post-payment audit records). encoded digital content, comprising: 

Communication processes do not need to be real-time. 15 (a) an external interface; 

For example, an auditing process can work as follows: The ( D ) a microprocessor for controlling said external inter- 

CRU first receives a message broadcast with some content face* 

that initiates an audit. The CRU then outputs audit data to the / c \ a ro emor y. 

playback device, which queues the data. Next, the playback 4 * - t , • 

device sends the audit data to the content provider, for 20 (d) 4 <TOtogr.pluc ; un.t connected between said micro- 

example by broadcasting it using low-speed radio commu- V t0CeSSO < and sa,d memor > ! thal P r ° ,ecls ^ ****** 

nication. After verifying the audit data, the content provider from said microprocessor by cryptographically trans- 

finally sends post-payment clearing commands with new form,ng data commumcated between sa.d micropro- 

content broadcasts ocssor and sa,d memor y ; and 

Some steps, such as address verification by the 25 d^ice key accessible by said cryptographic unit and 

CryptoFirewali, are recommended but may be omitted as inaccessible by said m. coprocessor, 

they are not always essential. Steps can also be substituted configured su f ch * at sa,d c OWph,c unit uses the 

„,:/k „*u- ^ .u * c, * ■ n ■ *i r* contents of said memory to transform at least one 

with other operations that are functionally similar. For , . , . , f . , . 

, j j c i_ r j i_ c data value received from said microprocessor, where 

example, address verification can be performed by forcing u f . A . f . F . "7 ' ' 

,., . »• i i / i 3 . . 6 30 the result of said transformation is required to decode 

invalid addresses to valid values (e.g., by setting or clearing . , . . ^ 

bits in the address to ensure that the address is in a proper - ™ Sai . . lgl a i - C J 3 ° te ° ' . 

, , . , t v w , \ r , I. lne device oi claim 1 where said memory comprises a 

range and abgned appropriately). Many steps can also be . ' ^^v 1 ™** a 

j j r- ill- n - c . nonvolatile memory, 

reordered. For example, the chip-specific portion of the ^ ™ . r , . - , 

computation described with respect to FIG. 7 can be XORed „ f -,1™* devlCe ° f da,m 1 where sa,d memor y °° m P nses a 

with the BATCH_KEY computation result instead of with 35 vo ™ l "f m ? mory f , . , . 

the BATCH_KEY computation input. Many other such 4 ' ^ d6Vlce ° f claim } where , 8 V d mem ^. «»«*™ .» 

simple variants will be evident to one of ordinary skill in the ^P««ntat.on of a r.gnfc key and where sa.d rights key is 

art J used in said transformation of said at least one data value. 

_ . . , . , . 5. The device of claim 4 where said rights key was 

-Hie pseudoasymmetnc function generator (and functions 40 received via said extemal interface in a fonn encrvpted 

it produces) can be used in applications other than content using said 

distribution. For example, stored value cards, electronic 6 ^ device of daim 5 where Mid device lates 

transit passes, software copy protection, challenge-response access t0 a pay television 

authentication tokens, and other applications where low-cost 7 ^ device of claim 5 where sakJ me com . a 

devices must carry secrets can all benefit from secure 45 nonvolatile memory 

cryptographic transformation circuits that are difficult to g ^ device of daim 5 where said me a 

reverse engineer. volatile memory 

The CryptoFirewali can include multiple cryptographic 9. The device of claim 5 where said rights key is stored in 

algorithms, some of which can be specific to a given said memory in a form encrypted using said device key. 

CryptoFirewali or batch, and others that are more general. 50 10. The device of claim 5 where said rights key was 

For example, in a large system with 25 million CRUs, it may decrypted by said cryptographic unit using said device key 

be advantageous to minimize the consequences if any indi- before said rights key was stored in said memory, 

vidua! CryptoFirewali is reverse engineered. As a result, 11. The device of claim 1 where said device key is stored 

groups of (for example) 100,000 CryptoFirewalls may be j n said memory. 

constructed with different algorithms. KDMs and/or REMs 55 12. The device of claim 1 where said device key is stored 

are transmitted separately to each of the 250 groups. m sa jd cryptographic unit. 

Any components that include microprocessors can 13. The device of claim 12 where said device key is stored 

receive code updates. For example, code in the playback as a combination of blown fuses on an integrated circuit, 

device, ICP, or the CryptoFirewali can be updated by the 14. The device of claim 1, 5, 6, 11, or 12 where said 

content provider. Code updates should be cryptographically 60 microprocessor, said memory, and said cryptographic unit 

protected (e.g., with digital signatures, MACs, etc.) To are implemented within a single microchip, 

ensure that interrupted memory updates do not compromise 15. The device of claim 1, 5, 6, 11, or 12 where said 

security, the CryptoFirewali can store memory update data microprocessor, said memory, and said cryptographic unit 

and addresses in a pending-write buffer, set a write-pending are implemented within a smartcard. 

bit, perform the write, then clear the write-pending bit. If the 65 16. The device of claim 1, 5, 6, 11, or 12 where said 

write operation is interrupted (e.g., due to a loss of power), microprocessor, said memory, and said cryptographic unit 

the write will either be lost completely or can be completed are contained within a card. 
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17. The device of claim 1, 5, 6, 11, or 12, further 
comprising a content decryption unit configured to receive 
said encoded digital content via said external interface, 
decrypt said content using said result of said transformation, 
and output a representation of said decrypted content via 
said externa! interface. 

18. A method for generating a cryptographic transforma- 
tion that is difficult to reverse engineer, comprising the steps 
of; 

(a) using a random source to obtain unpredictable data; 

(b) using a software-implemented cryptographic function 
generator with said unpredictable data to produce a 
machine-readable definition of a randomized crypto- 
graphic transformation; 

(c) implementing said randomized cryptographic trans- 
formation in an integrated circuit; and 

(d) using said integrated circuit to perform said random- 
ized cryptographic transformation on a digital datum. 

19. The method of claim 18 comprising the additional 
steps of: (i) using said integrated circuit to protect the 
distribution of encoded digital content; and (ii) using a result 
of said cryptographic transformation in said step (d) to 
decode said digital content. 

20. The method of claim 19 where said cryptographic 
function generator also produces a machine-readable defi- 
nition of the inverse of said randomized cryptographic 
transformation. 

21. The method of claim 19 where said inverse transfor- 
mation is used by a provider of said digital content to encode 
information distributed to said integrated circuit. 

22. The method of claim 19 where knowledge of the 
design of said function generator without knowledge of said 
unpredictable data does not enable the reverse engineering 
of said cryptographic transformation in said integrated cir- 
cuit. 

23. The method of claim 22 with the additional step of 
performing a security analysis to assess the likelihood of 
said function generator producing a cryptographically- 
sccure output transformation. 

24. The method of claim 19 where the result of said 
cryptographic transformation is stored in a protected 
memory. 

25. The method of claim 19 where the result of said 
cryptographic transformation is used to determine whether 
to modify a protected memory. 

26. The method of claim 19 where an input to said 
cryptographic transformation is read from a protected 
memory. 

27. The method of claim 19 where said cryptographic 
transformation has a Feistel structure. 

28. The method of claim 19 where said cryptographic 
transformation includes deriving an input to a shift register. 

29. The method of claim 19 where said cryptographic 
transformation is pseudoasymmetric. 

30. The method of claim 19 where said cryptographic 
transformation is a one-way hash function, and including the 
step of decoding said digital content using an output of said 
hash function as a decryption key. 

31. The method of claim 19 where said cryptographic 
transformation is a permutation. 

32. The method of claim 19 where step (d) is performed 
in a smartcard. 

33. The method of claim 18 where said cryptographic 
transformation is a keyed block cipher. 

34. The method of claim 18 where said step (d) includes: 
(i) transforming a first datum using said randomized 

cryptographic transformation; 
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(ii) using the result of said transforming to derive a second 
datum; and 

(iii) transforming said second datum using said random- 
ized cryptographic transformation. 

35. A method for storing a new cryptographic key in a 
tamper- resistant device, where said device contains a device 
key, comprising the steps of: 

(a) receiving a base update key and a smaller device- 
specific update value from a party that knows said 
device key; 

(b) transforming said base update key using said device 
key; 

(c) combining at least the result of said transforming with 
said device-specific update value to produce a corrected 
update value; 

(d) deriving a representation of said new cryptographic 
key by combining at least said corrected update value 
and said base update key; and 

(e) storing said derived representation in a memory. 

36. The method of claim 35 where said new cryptographic 
key replaces an old key, and where said old key is incor- 
porated into said derivation of said new cryptographic key in 
said step (d). 

37. The method of said step 34 further comprising a step 
of disabling said device if said new cryptographic key is not 
successfully derived. 

38. The method of claim 35 further comprising a step of 
decoding digital content using said new cryptographic key, 

39. The method of claim 35 where said memory com- 
prises a nonvolatile memory. 

40. The method of claim 35 where said step of deriving 
includes using a pseudoasymmetric function. 

41. A method for a first device to allow a user to purchase 
and gain access to digital content without bi-directional 
communication with the provider of said content, compris- 
ing the steps of: 

(a) obtaining a value corresponding to said content to be 
purchased; 

(b) storing a representation of said value in a nonvolatile 
memory; 

(c) using a process shared with a plurality of devices 
similar to said first device, cryptographically trans- 
forming at least a part of said stored representation to 
produce a content decryption key; 

(d) decrypting said content using said content decryption 
key; 

(e) allowing said content provider to audit the contents of 
said nonvolatile memory; 

(f) receiving from said content provider a command to 
make said memory available for reuse; 

(g) using a process that is not shared with said plurality of 
similar devices, cryptographically validating said com- 
mand; and 

(h) clearing said nonvolatile memory for reuse, 

where at least said steps (b), (c), (g), and (h) are 
performed in a tamper-resistant device. 

42. The method of claim 41 wherein said step (g) of 
cryptographically validating said command is secured using 
a device key, 

43. The method of claim 41 where said nonvolatile 
memory is connected to a cryptographic unit within said 
tamper- resistant device which uses cryptographic transfor- 
mations to secure access to said memory, and where at least 
said steps (c), (g), and (h) are performed by said crypto- 
graphic unit. 
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44. The method of claim 42 where said step (b) only 
proceeds correctly if said nonvolatile memory has been 
cleared. 

45. The method of claim 42 where said step (b) stores a 
different value in said nonvolatile memory depending on 
whether said nonvolatile memory is cleared for reuse or 
contains a previously stored transformation result, and 
where said step (d) only proceeds correctly if said nonvola- 
tile memory was cleared. 

46. The method of claim 42 where said tamper-resistant 
device is implemented in a single chip. 

47. The method of claim 46 in which said chip is a 
smartcard. 

48. The method of claim 46 where said digital content is 
digital music. 

49. The method of claim 46 where said digital content is 
pay television. 

50. The method of claim 41 where said tamper-resistant 
device is implemented as a smartcard. 

51. The method of claim 41 further comprising a step of 
said content provider sending a bill to a user of said device. 

52. The method of claim 41 where the audit process of 
said step (e) is cryptographically secured using a device key. 

53. A method for using a tamper-resistant device contain- 
ing a device key to protect access to digital content distrib- 
uted by a content provider, comprising the steps of: 

(a) storing said device key in a nonvolatile memory in said 
tamper-resistant device, such that said key is accessible 
by a cryptographic unit in said tamper-resistant device 
but inaccessible by a microprocessor in said tamper- 
resistant device; 

(b) distributing said tamper-resistant device to a user; 

(c) said content provider receiving from said user a 
request for privileges to access said content; 

(d) said tamper-resistant device using said microprocessor 
to receive a key derivation message transmitted by said 
content provider; 

(e) said microprocessor transmitting an encrypted rights 
key from said key derivation message to said crypto- 
graphic unit in said tamper-resistant device; 

(f) said cryptographic unit transforming said encrypted 
rights key using said device key to produce a decrypted 
rights key; and 

(g) using said decrypted rights key to decode said digital 
content. 

54. The method of claim 53 where said step (f) includes 
said cryptographic unit storing said encrypted rights key in 
a memory protected by said cryptographic unit. 

55. The method of claim 53 where said step (f) includes 
said cryptographic unit storing said decrypted rights key in 
a memory protected by said cryptographic unit. 

56. The method of claim 53 where said content is digital 
audio. 

57. The method of claim 53 where said content is digital 
video. 

58. The method of claim 53 where said content is dis- 
tributed by cable television. 

59. The method of claim 53 where said content is dis- 
tributed by satellite. 

60. The method of claim 53 where said content is dis- 
tributed by wireless broadcast. 

61. The method of claim 53 where said content is dis- 
tributed over a computer network. 

62. The method of claim 53 where said step (g) includes: 
(i) said cryptographic unit using said decrypted rights key 

to derive a content decryption key; 
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(ii) said cryptographic unit transferring said content 
decryption key to said microprocessor; 

(iii) said microprocessor further transforming said. content 
decryption key; 

5 (iv) said microprocessor transferring said transformed 
content decryption key to a playback device; and 
(v) said playback device using said transformed content 
decryption key to decode said content. 
1Q 63. A method for a first device to allow a user to purchase 
and gain access to post-paid digital video content, compris- 
ing the steps of: 
(a) obtaining a value corresponding to said post-paid 
video content to be purchased; 
is (b) storing a representation of said value in a nonvolatile 
memory; 

(c) using a process shared with a plurality of devices 
similar to said first device, cryptographically trans- 
forming at least a part of said stored representation to 

20 produce a content decryption key; 

(d) decrypting said content using said content decryption 
key; 

(e) allowing said content provider to audit the contents of 
25 said nonvolatile memory; 

(f) receiving from said content provider a cryptographic 
authorization to make said memory available for reuse; 

(g) cryptographically validating that said authorization 
corresponds to said contents of said nonvolatile 

30 memory; and 

(h) allowing said nonvolatile memory to be reused for 
storing subsequent purchases; 

where at least said steps (b), (c), (g) and (h) are 
performed in a tamper-resistant device. 
35 64, A method for using a tamper-resistant device contain- 
ing a microprocessor and a separate cryptographic unit to 
protect access to encrypted digital content distributed by a 
content provider, comprising the steps of: 

(a) storing a device key in a nonvolatile memory in said 
40 tamper resistant device, such that said key in said 
memory is accessible by a cryptographic unit in said 
tamper-resistant device but inaccessible by said micro- 
processor; 

45 (b) said tamper- resistant device using said microprocessor 
to receive a key derivation message transmitted by said 
content provider in response to said content provider 
receiving a request for privileges to access said content; 

(c) said microprocessor transmitting a value derived from 
50 said key derivation message to said cryptographic unit; 

(d) said cryptographic unit transforming said value using 
said device key to produce a first decoding secret; 

(e) said microprocessor using a secret inaccessible by said 
cryptographic unit to derive a second decoding secret; 

55 and 

(f) decoding said digital content using key material 
derived from said first decoding secret and said second 
decoding secret. 

65. The method of claim 64 where: 

60 

(i) said key derivation message is an input to said step (e) 
of deriving said second decoding secret; 

(ii) said value derived from said key derivation message 
is said second decoding secret; and 
65 (iii) said step (f) of decoding said digital content includes 
transferring said first decoding secret to a playback 
device for decoding said content. 
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66. A method for using a device to receive a cryptographic 
secret distributed to a subset of a group of similar devices 
that share a group secret and have individually -assigned 
group offsets, comprising the steps of: 

(a) receiving a non-secret input value from a party that 
knows said group secret, where said input value 
includes a group mask specifying said subset of devices 
that are authorized by said party to derive said crypto- 
graphic secret; 

(b) retrieving from a secure memory said group secret and 
said device offset; 

(c) transforming said input value using at least said group 
secret and said device offset to produce a transforma- 
tion result, such that said transformation result allows 
determination of said cryptographic secret if said 
device offset is specified in said group mask; and 

(d) storing said cryptographic secret. 

67. The method of claim 66 comprising the additional 
steps of: (i) receiving said group secret and said device offset 
from said party; and (ii) storing said group secret and said 
device offset in said secure memory; and where said secure 
memory cannot be modified by a user of said device. 

68. The method of claim 66 where said cryptographic 
secret is stored in a satellite television receiver, and com- 
prising the additional step of said receiver using said stored 
secret to decode encrypted digital satellite television pro- 
gramming. 

69. A tamper- resist ant smart card device for regulating 
access to encrypted television programs, comprising: 

(a) a serial sraartcard interface providing bidirectional 
communication with a playback device; 

(b) a microprocessor connected to said serial interface, 
configured to receive access control rules for said 
encrypted television programs and to output content 
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decryption keys for decrypting said encrypted televi- 
sion programs; 

(c) a first cryptographic unit, configured to participate in 
generating said content decryption keys if said access 

5 control rules allow access to said programs; and 

(d) a second cryptographic unit, physically distinct from 
said first cryptographic unit, configured to participate in 
said generating of said content decryption keys if said 
access control rules allow access to said programs; 

10 where each of said first cryptographic unit and said 
second cryptographic unit is configured to crypto- 
graphically enforce said access control rules if the 
other said cryptographic unit is compromised by an 
attacker. 

15 70. The device of claim 69 where said first cryptographic 
unit is implemented in software on said microprocessor, and 
where said second cryptographic unit is implemented in 
software on a second microprocessor. 

71. The device of claim 69 further comprising a nonvola- 

20 tile memory connected to said second cryptographic unit for 
storing purchase records for post-paid programs, and where: 

(a) said access control rules enforced by said second 
cryptographic unit include preventing access to said 
post-paid programs unless said nonvolatile memory 

25 contains a valid purchase record for said post-paid 
programs; and 

(b) said second cryptographic unit is configured to require 
valid cryptographic authorization before over-writing 
said purchase records in said nonvolatile memory. 

30 72. The device of claim 71 where said cryptographic 
authorization is a value generated by a provider of said 
post-paid programs and is specific to the contents of said 
nonvolatile memory. 

* * * * * 
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